home *** CD-ROM | disk | FTP | other *** search
- Subject: Re: user-written interrupt handlers
- Date: Tue, 8 Mar 94 18:54:42 CET
- From: Juergen Lock <nox@jelal.north.de>
- In-Reply-To: <9403071106.AA00523@hanauma.jpl.nasa.gov>; from "Howard Chu" at Mar 7, 94 3:06 am
- Message-Id: <9403081754.AA00150@jelal.north.de>
-
- Howard Chu writes:
-
- > >> Signal handlers aren't good replacements for interrupts; they take too
- > >> much time to be serviced -- maybe a tenth of a second, versus a few
- > >> microseconds for an interrupt handler. It would be unusable, for
- > >> instance, for the serial interrupts, while it would be quite appropriate
- > >> for "Monochrome Detect", say.
- > >>
- > >> Well, since my only purpose here was to drive my interrupt-driven sound
- > >> routines on the Falcon, that was just fine anyway. (Using the monochrome
- > >> detect interrupt, fancy that.)
- > >
- > > btw what is the difference, isn't monochrome detect level 6 too? :)
- > >(not that this should be a problem here...)
- > >
- > > cheers
- > > Juergen
- >
- > Heh. Well, I doubt a monochrome monitor will burn out in a few milliseconds
- > of bad video signal, and I know you won't hear a few milliseconds lag in
- > swtching the buffer addresses of a DMA-driven sound playback, but you could
- > lose several bytes in that amount of time in a serial interrupt handler.
-
- well whether you'll hear it depends on what you play back :) but when a
- cat >/dev/audio uses an interrupt handler that takes too long it will
- annoy uucico processes running at the same time as well as when its a
- serial interrupt handler with this problem...
- >
- > It's too bad there weren't a couple more DMA channels in the regular ST;
- > like one for the 68901 USART. Running that chip in sync mode would let you
- > do some really mean high-speed internetworking...
-
- btw anyone using the TT's SCC DMA yet? its too bad mega STe don't have it :)
- (and have all this SCC problems too.)
- >
- > Hm.... Now that I think of it, how could you call post_sig from an rs232
- > interrupt handler? You need to get back to receiving the characters of
- > the next incoming frame right away, so you need some way of firing off the
- > call to post_sig at a lower priority.
-
- hmm. if there is no one else hooked into the same vector `above' you
- you could reset the interrupt level from the stack after flipping the
- 68901 in-service bit and then send the signal and rte... (is post_sig etc
- re-entrant(sp?) ?)
-
- > I guess you could set another flag
- > to indicate SLIP or PPP end of frame, and have a VBL routine check that...
-
- ...and otherwise (interrupt level on stack was >= 5) do this.
- >
- > On a different topic, I've seen my system freeze up completely from time
- > to time, only to return to regular operation some indeterminate amount of
- > time later. Anyone else seen this? (I'm still talking MultiTOS here.) No
- > keypresses or button clicks register, drop-down menus don't drop, etc.,
- > only the mouse-cursor tracks. Awfully disconcerting...
-
- maybe the disk driver? when my quantum disk gets accessed while it
- recalibrates i get a few second `sleep' too. but that has nothing to do
- with multitos...
-
- > -- Howard
- cheers
- Juergen
- --
- J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
- ...ohne Gewehr
- PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA
-